채용을 하는건 10+년차 시니어가 되고나서야 할만한 경험이라고 생각했는데, 내가 스타트업에 다닌다는 사실을 잊고 있었다.(지금은 과거형이 되었지만..) 팀에 백엔드 개발자가 필요해서 TO를 1-2명 정도로 열어놓고 채용을 sub로 함께 해보는 특별한 경험을 잠깐 해보았다. 회사가 작았기 때문에 가능했던 경험이고 앞으로의 커리어에서 언제 또 할지 모르겠다. 채용하는 입장이 되어보니 이번 또는 예전에 구직활동을 하면서 내가 잘못 생각했던 것들이 속속 떠올랐다. 그래서 정리해보는 채용하는 입장에서의 이력서-과제-면접.
(나~~중에 내가 다시 구직자가되거나 면접관이 되거나 했을때는 기억나지 않을거같아서 기록하는 주관적인 생각들이며, 사실 5년차 나부랭이가 이런 글을 공개적으로 써도되는지 모르겠다…)
이력서
안타깝다고 생각한 이력서들
중요하고 좋은 경험들이 1-2페이지 이후에 적혀있는 이력서
채용담당자가 너무 바쁘면 거기까지 읽지 않을 수도 있다…(근데 나는 다 읽긴 했음. 진짜 좋은 사람인데 발견 못할까봐?) 예전에 자소서 컨설턴트가 했던 말 그대로 나도 이력서를 초반에 흥미로우면 계속 집중해서 읽고, 아니면 스키밍을 하게 되었다. 반대로 너무 보고싶지 않은 학력, 개발과 무관한 경험들이 앞에 적혀있으면 답답했다.
두루뭉술하게 적혀있는 경험
‘xx팀 쿠폰 도메인 유지보수’ 와 같은 추상적인 말로 경험을 표현할 때 가장 아쉬웠다. 유지보수를 무엇을 어떻게 고쳐본 사람인지 알 수가 없었다. 도메인상으로 봤을 때 우리 팀이 하는 일이랑 비슷한 일을 해봤더라도, 잘할 수 있는 사람인지 확신이 서지 않았다.
예전에는 괜히 이력서 크기를 줄이려고(그 당시에는 한두장 안에 다 담겨야 한다고 생각했음), 또는 면접 때 어차피 자세히 물어보던데?? 하면서 초간단 요약을 해놓기도 했었는데 요약도 요약 나름이다.
조금 더 서류를 검토하는 사람에게 확신을 주기 위해서 최대한 성과 위주로 명료하게 경험을 표현하는게 좋을 것 같다. - 다만 너무 텍스트가 많으면 읽는 사람에게 부담이고, 강조하고 싶은게 강조될만큼은 추상화를 하는게 좋을듯하다.
눈에 거슬리는(?) 이력서
ex. 포맷이 와장창 깨진채로 제출, 보고싶지 않은🥲 사진(뭔가를 먹고있는 사진 등 암만 생각해도 프로필용은 아닌), 개발과 무관한 경력이 너무 길게 써져있는 이력서
예전에 이력서에 사진이 필요하다고 생각하고 사진을 신경쓴 적이 있었는데 이번에 이력서에 첨부된 사진들을 보며 대부분 했던 생각은 ‘사진을 붙여놓으셨네’ 정도였던거같다.
감탄했던 이력서들
프로젝트 마다 적극적인 개선 경험이나 새로운 기술을 도입했던 좋은 성과들이 줄줄이 적혀있는 이력서
실제 웹상에서 운영중인/운영되게 만든 사이드 프로젝트가 있고 링크로 들어가서 확인해볼 수 있었던 이력서
채용 플랫폼 통해서 여러 회사에 뿌리는 이력서가 아니라는 확신을 주는 이력서 - 간략하게라도 우리 회사를 지원하는 이유가 적혀있는 이력서
예전과 조금 바뀐 생각들
과거의 나는 서류 탈락을 하면 그건 100% 내가 이력서를 잘못써서 + 뭔가 부족해서 그런거라고 생각했다. 그럴수도 있다. 근데 100%는 아닌거같다. 지원한 회사의 상황이 어떤지 지원자는 모른다. 내가 채용을 할 때 우리 회사는 자원이 넉넉한 상황이 아니었기에 아얘 실무 경험이 없거나 없다시피한 사람을 risk taking하며 채용하고 온보딩 시켜줄 수 없었다. (우리가 규모가 좀더 크고 TO가 많았다면 과제로 넘어갔을 사람들이 꽤 있었다.) 진짜 너무 괜찮은 이력서임에도 눈물을 머금고 탈락에 한표를 던졌다. 비슷한 이유로 쌓아온 경험의 결이 안맞을 때도 서류통과는 어려웠다. TO에 비해 지원자가 생각보다 많아서 처음 생각했던 수준보다 기준치가 높아지기도 했다.
⇒ 결론: 서류탈락에 너무 마음쓰지 말자. 광탈이라며 눈물줄줄 흘리지 않아도됨…
과제
‘이사람이 평소에 어떻게 일하는가’ 가 과제를 통해 많이 드러나는 것 같다.
요구사항 이상으로 너무 잘하려고 했던걸수도 있는데 요구사항에 비해 과한 기술을 써서 복잡도만 높여놓고, 어떤 배경으로 그런 선택을 했는지도 불분명한 사람은 좋지 않아보였다. 그냥 그 기술을 써보고싶었던 것인지도 모르고..
과제 제출할 때 readme에 ERD, 기술스택 등 기본적인 것들을 잘 써두는것도 좋은데, 과제를 하면서 어떤 고민을 했고 신경쓴 포인트가 뭐였는지 요약해두면 좋겠단 생각을 했다. - 어필 포인트가 되지 않을까? 그런데 이런 분을 잘 보지 못하긴 했다.
면접
자기소개를 엄청 잘할 필요는 없는데 최소한 긴장해서 할말을 못하지 않으면 좋겠다.
나도 이렇게 망한적 있는데 자기소개를 너무 열심히 준비했고 괜히 면접관들에게 압도되어서 그랬다. 근데 그렇게 긴장하는거부터가 다 망치는거같다. 면접관 입장에서는 긴장을 최대한 풀어주면서 그의 진가를 보려고 노력은 하는데 그 이상으로는 해줄수 있는게 없다.
‘뛰어난 개발자인가’ < ‘우리 팀에 왔을 때 잘할 수 있는가’를 본다.
구직을 할때는 ‘뛰어난 사람’ 이란 걸 어필하는데만 너무 시간을 쏟았던것 같기도 하다. 근데 채용을 할 때는 계속 ‘우리 팀에 왔을 때 저사람 괜찮을까, 문제 상황에서 어떻게 소통할까, 개발팀에 좋은 영향을 줄 수 있을까’ 등등을 생각하고 판단이 안서면 더 질문하게 되었다.
기본적인걸 물어보면 설명을 어떻게 하느냐를 보며 그 사람의 깊이가 어느정도 보이는거같다. 그래서 경력자라도 기본적인걸 묻기도 하게 되는거같기도 하다… 잘 설명할 수 있는 사람이 되어야지 ㅠㅠ
문제 해결 경험을 구체적으로 이야기
면접관과 문제와 해결에 대한 context를 형성하기 위해 다양한 정보를 제공하게 된다. 당시의 상황, 이 일을 왜 해야했는가, 기술은 왜 선택했는가, 결과, 결과가 안좋았다면 배운점들. 그 과정에서 이해가 안가면 추가적으로 질문도 하게 된다. 일단 면접관을 이해시키는데 성공하고, 그다음에 discuss할 수 있어야한다.
—
다음에 채용담당이 된다면
이번에 배운것1: 채용은 회사와 팀을 브랜딩하는 자리이기도 하다.
이번에 배운것2: 채용하는 이에게 무엇을 기대할 것인가를 명확히 해야한다.
좋은 질문에 대해, 면접을 한다는 것에 대해 좀더 많은 연구를 하고 면접에 들어가면 좋겠다.
질문 하나하나 좀더 의도를 담고, 상대가 어떻게 이 질문을 받아들일지를 생각하기
준비한 질문을 했음에도 역량에 대해 명쾌하지 않을 때 추가로 할 수 있는 질문들 등 여러 상황 플로우를 고려하기